RTS2 White Paper
Introduction This document should give both new and long followed RTS member where I'd like to take the next generation of RTS. It like any other document on the RTS Wikia is open for discussion, suggestions, and new solutions from the community. This document will go through the history of Run8, RTS, other servers, the software that made RTS what it was, and what lies ahead. What RTS has done in the past It seems like just yesterday, but in many ways was so long ago (over 5 years as I write this on Labour Day 2017). Back then Run8 had a simple tag system. Creating trains in the TMU was difficult, offline as it is today, and a challenge to create new trains. Lots of work was required by admin teams to create and tag the trains. Not all programs have easy to read data that the user can upgrade. In fact it was even easier in Run8 then Run8V2. Fortunately the team at Run8 (I've heard rumor keeped the XML intact for V2 to help RTS) left the XML alone for the train files only. Due to the increased risk of pirating, and other threats the XML's for everything else was removed. As I had a background in programming, I wanted to use my talent to further my hobby. Manipulating data files, and simple programming was something I knew I could handle. After a brief stint with the beta team both before, and after the release of Run8, RTS moved from concept to reality. The task for RTS was simply to take the limited number of rolling stock and power, to build multiple custom trains based on user defined data. The data would come in the form of what trains to run, what waybills, what routes, and what spawn points. From there it would continue to offer tagging options to create similar options for available empties in yards brought back by local trains for further distribution. RTS Reliance on manpower RTS like other major servers brought like minded people to operate trains. Unlike some servers that focused on either one location, or had multiple servers, RTS had a network of servers. It wasn't always that way either, as when I first started out I ran California on a set schedule that varied a bit drawing people in through the week. As the routes and servers grew, more people had choices of what servers and groups were right for them. But other train sims not having the physics of Run8, did have the eye candy. Some were tired of the politics, or simply avoided MP all together from day 1. Though routes began to grow, and there was promise of even a 4th route once, Run8 after 5 years essentially has never gone beyond 3 regions (with routes that simply joined in adding to the network). It's hard to say what factors have done what, as people's needs have many variables. At one time Run8 at many servers, then dropped to a select few. DAMS was the first that went to anarchy mode (something I recall John Greenstone saying would never make sense of being used). At the time I agreed since you had such a loss of control as a host, but DAMS proved it could work. Because there was so few servers now at this point (simply because manpower justified interest in running) for me and others we were competing for manpower to make our servers interesting. I upped the ante and said if we go anarchy let's try 24/7. Within days or hours (hard to say) DAMS followed suit, and then almost every server went to this model. Ease Of Access vs. Manpower Ease of access that 24/7 would bring to the table was a revolution. But it also quickly became evident that if you didn't have a base, advertisement, and concepts people were interested, you lost clients. I remember many times when I had a 24/7 server watching people connect then in minutes leaving with nobody around. As a server provider it was a frustrating feeling. Now the good part for me is at least I had the RTS system to fall back on. But even I was getting tired of running on territories that appeared lonely regardless of operations. The other factor for RTS, and I suppose other servers that had any kind of operations or switching was that manpower. In order to get the cars to industry and back out, you needed people. People to run the trains (yes RTS needed that as well despite it's reputation to focus only on switching), and of course switching and running of locals. Many times I would see what RTS called a cycle get longer and longer. The cycle was a measure it took us to run a set number of trains to represent a day. This in it's prime could be 7 to 14 days, I seen it once hit 2 months. Run8 Development & Future Projects As mentioned the routes continued to grow. What started as 1 Mojave Sub to Barstow, expanded today to about 5 subdivisions, 2 hump yards, and a number of industries. They are still to this day have plans to expand further into LA, and who knows where beyond that. But we also had new routes to get our hands on as well. Both Florida and Selkirk a few years back was under development. Today both routes has had at least 1 expansion now into an add on route each. One thing that I noticed as both a host and client was that despite bumps in interest, the numbers spread out thin among what people like to run. So now not only did you have people liking their favorite servers, but now their favorite routes. Again the thinning meant longer turnaround times to get work done, and more difficulty in people finding times of day where they could count on at least 1 or more others online to run with. There was one thing to look forward to however, and that was AI. We never knew what it was going to be we knew it was going to be special. In the meantime RTS still had some core interest mainly in the California and Florida servers in anticipation at certain days and times to keep things flowing. The wait seemed like forever, and there was times I just needed to take breaks and go find something else to do. It was around this time that I gave up the California Server if I recall to focus on development of either Florida or RTS. Didn't get too much done but it gave me something new to sink my teeth into while I patiently waited. To be honest I just was happy to have the break, and didn't get much done. I did manage to befriend a programmer in Mike Wierowski (Ski). We had met on my server as different core people came and others filled the void. Before the files got all locked down, Ski was able to make a great change in RTS that solved some of the issues V1 had faced. But not long after the changes, the big change came. Run8 V2 was finally here. Run8 V2 Changed Everything So the wait was finally over by the end of 2016 it was finally here. Unfortunately so was some of the changes Ski made because we lost access to the route files. As mentioned we fortunately to this day still have the XML files. The big change was the AI, and the ability of industries to load and empty. This not only solved a manpower issue with lack of people to run trains, but also admins to tag industries. For this it was a win win. But unfortunately V1 of RTS was already beyond it's own capacity, and V2 of Run8 meant changes were needed if RTS was going to ever work. For me personally though the old school thought of 24/7 servers was not as important. Yes I do want people to have access to what they like at various times, but the manpower requirement from the server is not as big of an issue. Yes massive expansion brings it's own manpower issues regardless, but just getting something to run can be as simple as single player, or 2+ people in more complicated territories. I will be getting into some of these ideas in an upcoming white paper on Florida, but for now I'll stay focused on RTS2. There are many shortcomings of Run8 in the way it assigns tags and commodities to trains. It also has serious issues in the random train spawners that are not realistic. The good news I have found is there are ways to overcome these shortcomings. That being said it's still not perfect, and as prototypical as RTS once was. So Why Isn't RTS2 Here? So with all these issues, and possibly a reduction in how much RTS software really needs to do why the delay? This is two fold, and deals with my desire and skill, vs Ski's skill and time. I have the desire, but I really am an old school programmer. This takes away from my desire because I'm content with just running. I've hosted, and programmed in the past 5+ years and I'm tired and don't want to go back to it if I can help it. But in writing this you can tell I certainly have lots of new ideas as you will see below. The other side of this equation is Ski and others filling the void. Ski has been working like a dog now for several months. He did toy around with RTS2 just like I did personally. He ran out of time, and I have run low on desire. But things are beginning to change. I'm finding that I can destroy some of my bad habits in viewing crappy YouTube videos that drain my available time. I get easily distracted by what else is out there, and can easily just like a TV that I barely watch get lost in it. I was smart enough to avoid my TV for the most part, but I haven't been so easy to get away from YouTube. Even today I made steps to try and change to an even healthier lifestyle. This has helped fuel my ideas and enthusiasm further. On the other side resources may also be coming in the form of help. Ski's workload should be reducing, though I don't know at this time if his interest will be there. Others have expressed some interest, so there is the possibility I may get the help I need, in the not too distant future. What needs to be developed? I've already gone through the XML, and there isn't too much difference in V1 & 2 Run8 XML for the trains. However as mentioned RTSV1 already was beyond capacity of new rolling stock. The waybills may still work the same, but I have thought of other ideas that may be more appropriate. I've also found that Run8V2 may be more forgiving in the placing of trains. Because the new industry system works relatively well, the tag system for me is not as required as it once was. Beyond the basics there are a host of other things that can make RTS better than ever before. Being able to have engines that not just show up but have a probability would be a good start. I've always wanted to have a better user interface, perhaps with better reporting and tracking. I'll go into a few of these details before calling it a day on this document. Survey Module Believe it or not this was already written by me earlier this summer. It was my first attempt at dealing with the XML file where a few experiments also proved to be encouraging. The module simply takes 2 survey trains. survey1 & survey2 are saved by the user. The user simply starts 1 where he wants the trains to start, and is as long as he wants it to spawn. Survey2 is an overlap to catch all the missing small track sections. So half way past the string of cement hoppers (what I recommend as the shortest car in Run8V2) you'll pick up lots of real estate. However this will not pick up everything as I have found out. The data can then be exported to a sheet for further analysis. The sheets are better than program code simply because it's complicated and humans are much better to detect patterns. Simple areas where track section numbers are missing can easily be spotted by a human, but still hard for my coding to pick up. The good news in this is I have found Run8V2 to be VERY forgiving. I don't recall V1 being as forgiving with this and that is going outside the limits of the track section. So let's say you have 4 500m sections, and they are all straight. You can now take the 1st 500m track section as a reference and make it 2000m in RTS2. As long as it's straight or is not in more than 1 curve, you should have no issue. The train when spawned may spawn straight out past the next curve but it will find it when the parking brake is released. S curves however are problematic. My recommendation with this is to only use this technique on the last curve. Straight sections should have no restrictions. I haven't gone much further than this at this time. Waybills vs. Probability Demand The way RTS1 worked was you had a waybill file of every possible movement. In fact the trains could be different yet similar, because they followed a call up for each waybill in order. If you had 1000 waybills and 10 trains, the system would randomly call a number between 1 and 1000, 1000 times. This would set up the variables to pick the right cars for each train and the rest is simply program execution to make those trains. Probability is something that caught my eye actually from Run8V2. I liked the concept of calling various train types not the execution. But I did think the practice could work in a probability demand structure. I like how Run8 V2 actually lists all the industries. To it I would possibly add some kind of region the source comes from and that too could be a probability. This would change the way in which RTS generates calls for cars, something I've pondered about for a bit now. Probability Engine Configuration In V1 of RTS we had a limit of 9 engines that had a hard coded set up of configuration based on required tonnage. Though I think the tonnage requirement should be maintained, other rules such as DPU use and lines that don't use DPU should be introduced in this decision. A configuration should go on to have a probability of various engines of the user's data to appear as well. This would give more realistic power lash ups. The inspiration for this came in the pros and cons of how engines are chosen in Run8V2. I like how you can choose the different engines and road names. I also like the rules in place based on railroad. Proper HPT values were already part of V1 RTS and that will stay the same. Random Weights I like how Run8V2 has actually done a good job with the random fuel values (perhaps this is one rare occasion it's too random). Not so sure individual engines would differ that much in fuel, but perhaps that is just me. What I absolutely don't like is fixed fully loaded, fully empty cars. In real life fully loaded cars would only show up in bulk commodities. It certainly wouldn't show up in IM and BOX cars. Even tanks I'm not so certain of. Anything that has a different density in the same kind of car to me is subject likely to some kind of variance. This is where I'd like more discussion on to get more protype info on this. We've tried this in the past, but only got limited data. But speaking of data, the data must be user defined in order to give realistic values. Just making random weights is not the right way to go on this. Capacity Safeguards One shortcoming of RTSv1 was how based on a fixed number of waybills, we often ran past our capacity in many aspects. The capacity that stands out the most was the spawn area. RTSv1 never properly put a cutoff on the length of a train in a given area could be. But capacity of length to me is not the only issue. I would like to see more capacity put into demand as well. Though it is common for certain industries to receive over capacity, it's not common for all. For example any commodity with an expiry date or some form of spoilage would certainly NOT be stored in a yard or siding to wait for a spot on the dock. Simply put some shipments if they don't have a dock available would not ship. The Tag System This is something that on first thought, I really didn't see a need for. However despite the way Run8V2 handles loading and unloading it's great but not perfect. One thing that stands out for me is the use of available empty in yards. Now not having to tag is an a big help to hosts and ADMINS. I think that the Run8V2 industries should still be set up, but not used on the basis of generating trains. If RTS2 takes over this responsibility then the choice of tags can still be used that would make RTS2 even better than it was before. Here are the benefits, we used to get quite a bit of extra empties in the yards. Today we get NO empties and many yard tracks are left empty. This is because Run8V2 simply assigns the empty to head back on a train to a new destination. Run8V2 however can assign anything including yards if it is set up properly. This can be huge because now it can even assign empty transfers from one railroad to another. If a certain industry is known for giving back lots of empties, and yards gets filled there is an easy solution. Simply have it tag fewer yards, and actually be requested back at certain industry and regions. This makes it even better than before simply by regulating too much extra cars, yet having the program Run8V2 decide where the demand for said empty is (just like the loads). Another benefit is the tag system in Run8V2. It makes it very easy to set up tags based on industries in the system. Even if it is not a real industry, setting up a fake industry is a piece of cake. The industry doesn't act like other industries, but can be selectable and that is what is important. Makes it much easier on an admin or YM to quickly deal with a yard. Schedule & Call Sheets One thing that Run8V2 has failed at is providing a realistic train calling procedure for it's AI trains. Top this with a procedural based random call generator and patterns easily come up quick, and tend to repeat. What was originally shown however was a TD3 style system in some late screenshots of development. For whatever reason it was scrapped. Now I have my own way of calling trains and avoid personally dealing with this. I even go so far to have trains spawn from the AI menu at my will, sit there briefly for a few seconds, and use the actual Run8V2 tag system. This allows more realistic timing of trains and tags to make the trains interesting. The only thing that isn't perfect is the trains themselves, but it's at least something I don't mind running. The before mentioned waybill systems will take care of what actually gets put on these trains. But scheduling them and knowing when to spawn them is still something the user has to do. In order to help the users who are not as comfortable with complex formulas and Excel sheets I recommend a TD3 style schedule system. This can easily be expanded to include call sheets. Having the schedule and call sheets will be based as all RTS data as user defined values. They can simply set the limits they want their trains to show up, what the optimal time is, and how late it's likely to be. Further Automation I've already found some clever things to do with using yard tracks to turn around trains in a hurry. Automation just like the real world is used to replace human activity. It's not meant to replace MP, but simply make the user feel like he is part of a busier system just like AI has done. What RTSv1 was able to do was to allow interchange systems to work by specifying spawns simply spawn without an engine, and this should be continue. However there are other useful tools that would help admins, YM, get more out of their RTS experience. Hump and industry capacity, keeping track of the cars in the system already generated are some of the easy targets. Most of this can be improved by better user interfaces and avoid the use of spreadsheets. It can even further be automated to possibly include web based applications that run as a server allowing clients or even the ED (if figured out) to register what is going on automatically. Of course these are not my top priorities and is the last thing I'll add to what I see RTSV2 in being. Conclusions As mentioned I'm always open to ideas and suggestions. I'm also open to a replacement of RTS if some others vision takes it over. It would be nice to see what Run8 possibly has in store for the future to help on their end, but this is often difficult to find out until it's right on us. This is not an all inclusive list. I will always read suggestions and perhaps can update this list in the near future. Thanks for reading! Sean (SurvivorSean) Murrell Creator and lead developer of RTS